Prior to the execution of a query from an application server, a database generates an execution plan. This plan contains operations to be executed in order to ensure the correct results of a query and a proper order of their execution. The generation of the execution plan relies heavily on the presence of database metadata, e.g., a number of data tuples in certain database tables, or the presence of certain database tables and columns. Therefore, the execution plan generation has traditionally been performed in the database process.
Application servers execute large amounts of database queries. The queries are transmitted in form of an SQL statement (String). The database server parses the query, generates the execution plan and executes the query. After the query is processed and the query processing is complete, the results are returned to the application server as a reply for further processing.
For small queries, the effort required to generate the execution plan amounts to a relatively large percentage of the overall query execution effort. Furthermore, the generation of a query execution plan in the database server itself operates on central data structures in the database, heavily contending them.
Some solutions to address these problems involve the use of prepared statements in relational databases. However, the prepared statements only provide a handle to pre-parsed statements, and potentially to the execution plan. The parsing of the queries and execution plan generation must still occur in the database process.